Kanban Practices

For many engineering managers, “Kanban” conjures up images of sticky notes on a board, neatly arranged in columns like “To Do,” “In Progress,” and “Done.” And that's a good start. But truly leveraging Kanban’s power goes far beyond simply visualizing work. It's about building a system for continuous improvement, limiting work in progress (WIP), and fostering a predictable, flow-based approach to delivery. Do you struggle with unpredictable delivery timelines or frustrated team members bogged down by context switching? Kanban, when implemented thoughtfully, can address these challenges. In over 20 years leading engineering teams, I've seen Kanban transform stagnant groups into highly efficient, responsive units. Here’s how to move beyond the basics and deepen your team's Kanban practice.

The Core Principles – Beyond Visualization

Yes, visualization is foundational. It exposes bottlenecks and makes work transparent. But it’s only the first layer. The true strength of Kanban lies in these core principles:

• Visualize the Workflow: As mentioned, this is where most teams start. But go deeper than just task status. Visualize all stages of work, including code review, testing, and deployment.
• Limit Work in Progress (WIP): This is the game-changer. WIP limits force prioritization, reduce context switching, and accelerate flow. More on this below.
• Manage Flow: Focus on moving work smoothly through the system. Identify and address bottlenecks to improve overall throughput.
• Make Process Policies Explicit: Document how work moves through each stage. What defines “Ready for Development”? What criteria must be met for “Code Review”? Transparency avoids ambiguity and speeds up handoffs.
• Implement Feedback Loops: Regularly inspect and adapt the process. This is where retrospectives are crucial.
• Improve Collaboratively, Evolve Experimentally: Kanban isn't about rigid adherence to rules. It’s about continuous learning and incremental improvements.

The Power of WIP Limits: Not Just a Number

I’ve seen teams resist WIP limits initially. It's natural for teams to push back against perceived constraints, so acknowledge this resistance and emphasize the benefits. The truth is, multitasking is a myth. Cognitive switching costs are significant, leading to reduced productivity and increased errors.

Here’s how to approach WIP limits:

• Start Small: Don’t overhaul everything at once. Begin by limiting WIP in one stage of your workflow, typically "In Progress."
• Data-Driven Limits: Don't just pick a number out of thin air. Monitor your team's throughput over a week or two. What's the average number of tasks completed in that stage? Start with a WIP limit slightly below that number.
• Pull System: Instead of assigning work, team members pull tasks from the backlog when they have capacity. This self-organization fosters ownership and reduces bottlenecks.
• Expedite Carefully: Exceptions to WIP limits should be rare and clearly defined. A true "expedite" should only be used for critical, time-sensitive issues. Overuse defeats the purpose.

Visualizing Flow: The Cumulative Flow Diagram A simple Cumulative Flow Diagram (CFD) is incredibly powerful for visualizing the impact of WIP limits. It shows how work moves through the system over time, highlighting bottlenecks and areas for improvement. By tracking the bands on the CFD, you can quickly identify stages where work is piling up and adjust WIP limits accordingly.

Feedback Loops & Continuous Improvement: Meetings & Retrospectives

Kanban is inherently iterative. Regularly inspecting and adapting your process is essential for sustained improvement. This is achieved through focused meetings and effective retrospectives.

• Replenishment Meeting (15-30 mins, weekly/bi-weekly): The team discusses and prioritizes items from the backlog, ensuring the Kanban board is stocked with well-defined work.
• Service Delivery Review (30-60 mins, monthly): Review key metrics (cycle time, throughput, lead time) to identify areas for improvement. This is data-driven, not a blame session.
• Risk Review (as needed): Identify and mitigate potential risks that could impact the flow of work.
• Operations Review (Cadence varies): High-level review of the entire system and key performance indicators.

Retrospectives that Drive Action: Don’t fall into the trap of predictable, uninspired retro formats.

• Vary Your Formats: Experiment with different retrospective techniques (e.g., “Start, Stop, Continue”, “Mad, Sad, Glad”, “Sailboat”).
• Focus on Systemic Issues: Don’t just fix individual incidents. Look for patterns and underlying causes.
• Actionable Items: Every retrospective should result in concrete, measurable action items. Assign ownership and track progress.
• Tie Retros to Data: Use metrics (cycle time, throughput) to objectively assess the impact of changes.

Tools & Technology (But Don't Over-Rely On Them)

Tools like Jira, KanbanTool, or even a physical board can facilitate Kanban, but they are not the solution. The process is more important than the technology. Choose a tool that supports visualization, WIP limits, and metrics. Avoid over-complication – keep the board clean and focused. Remember: the tool should serve the process, not the other way around.

Final Thoughts

Kanban isn't just about a visual board. It's a mindset, a way of thinking about work that emphasizes flow, continuous improvement, and collaboration. By moving beyond the basics and embracing the underlying principles, you can unlock your team’s full potential and deliver value more consistently. It requires patience, experimentation, and a commitment to continuous learning. The benefits – a more predictable, responsive, and engaged engineering team – justify the effort required.

To get started, implement a WIP limit on the 'In Progress' stage of your workflow next week, and track the impact on your team’s throughput. Consider experimenting with different retrospective formats to find what works best for your team. Don't be afraid to adjust your approach based on data and feedback.